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MULTIPLEJUEyi^^UBLIC KEYmg RARCHY FOR 
PERFORMANC E AND HIGH S ECURITY 



CROSS-REFERENCES TO RELATED APPLICATIONS 
This application claims priority fi-om U.S. Provisional Patent Application 
Serial No. 60/1 17,788 filed on January 29, 1999 and firom U.S. Provisional Patent 
Application Serial No. 60/128,772 filed on April 9, 1999, the disclosures of which are 
incorporated in their entirety herein by reference for all purposes. 

BACKGROUND OF THE INVENTION 

This invention relates in general to security in digital communication 
networks and more particularly to the establishment of a multiple level public key hierarchy 
in a digital communication network that provides a scheme for changing keys with a choice 
of secxuity and performance parameters. 

Public key systems have become a very popular means for providing security 
in digital systems. Public Key Systems (PKS) have two different keys, one for encryption, or 
signing, and one for decryption, or verifying. This separation of keys has great security value 
in that the sign/encrypt fimction can be securely isolated firom verify/decrypt fimctions, as is 
appropriate for the typical use of these keys. Public key ssytems are also known as 
asymmetric systems, or crypto systems, as opposed to non-public key systems that are known 
as symmetric, or secret key, systems. 

Secittity is crucial in the case of authentication, where the presence of a 
signing key in a verifying entity presents substantial risk to a network. The loss of a signing 
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key means that an unauthorized party can synthesize apparently legitimate messages, thereby 
fooling the receiver into accepting said messages. 

Thus, it is desirable for the isolation characteristics of public key to be made 
available in operations involving a transmitter (who encrypts and/or signs) and a receiver 
5 (who decrj^ts and/or verifies). 

As digital processing, and transfers of digital information, become 
increasingly popular it is necessary to ensure that the information processed and handled by 
these systems remains confidential, or secure, as desired. For example, the field of digital 
telephony needs to protect the voice data that is transferred over a network, such as the 

10 internet, if such voice data communications are to be protected. Also, large systems such as 
a digital telephony network, the intemet, a video data network, etc., must have digital 
"infirastructures" that are not easily broken into by people who may wantonly, or illegally, 
seek the information, services, or other value fi-om such systems. Such systems need to be 
highly resistant, or immune, to many forms of thefl. 

15 However, a problem exists with today's public key applications because the 

use of longer, more secmre, keys means that more processing resources are required to 
perform the encoding or decoding fimctions. Such resources as processing cycles, memory, 
number of transistors (i.e., chip "real estate") bandwidth and the overall time it takes to 
perform an encoding or decoding fimction are vital to efficient and fast coding operations. 

20 Unfortunately, when a key is of sufficient length to guarantee an acceptable level of security, 
it often means that the time required to perform the coding fimction is prohibitive in a 
particular application. 

For example, in a digital telephony application, many thousands of small 
packets of voice data must be transferred each second. The speed at which these transfers 

25 must take place leaves very little time for coding operations using long keys. Today's typical 
resources may only allow fast and efficient coding operations with small key sizes where the 
keys are too easily broken. For this reason, most very high voliune and high fi-equency 
coding applications have avoided using public keys, or have used public keys sparingly or 
only in low performance applications. 

30 



.1. 0 O »-l"«3J.0 « J. T-U X 



WO 00/45546 PCT/USOO/02170 

3 

Public Key Performance 

Typically, public key processes are thousands of times slower than the nearest 
equivalent non-public key (or symmetric key) approach. This is due to two effects: 

1 . The mathematics behind public key mean that not all numbers of the 
5 correct size to be a key are actually valid keys. This has the effect of lengthening the key 
size far beyond N bits to achieve a security level of 2*^; e.g. a 1 024 bit RSA key has a 
security level equal to about 2^°, rather than 2^°^'*. Ergo, to perform key operations at a 
security level equivalent to 90 bits, much larger and slower 1024 bit keys must be used. In 
non-public key ciphers, an 90 bit key tj^ically provides a security level of 2^. 
10 2. The mathematical operations of pubUc key encryption and decryption 

are not performed with fast and simple boolean operations, as with non-pubhc key ciphers. 
Algebraic operations such eis multiplication and exponentiation are used, which are bit-for-bit 
much more burdensome than boolean-type operations. 

In general, public key operations are more burdensome than non-public key 
15 operations, and many more bits of key are needed to achieve the same level of security as 
non-public key ciphers. Together, these effects mean that pubUc key operations are 
thousands of times slower than non-pubhc key operations. 

Improving Public Key Performance Using Special Keys 

20 Unlike non-public key algorithms where execution time is independent of the 

speciJSc key value, not all public keys require the same amount of time to encrypt/sign or 
decrypt/verify. Special Iceys can be chosen for improved performance, so long as the reduced 
security that unavoidably comes with these special keys is also acceptable. This can help 
performance for some encrypt/decrypt or sign/verify operations. 

25 Assuming no special keys are chosen, then a performance burden exists for 

both encryption/signing operations and for decryption/verification operations. Neither the 
encrypf sign operation nor the decrypt/verify operations would be exposed to reduced 
security, since no special keys are used for either of these. The combined operation of 
encryption followed by decryption, or signing, followed by verification would be 

30 burdensome and the total amount of time required would be long. 
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In the case where one key is a special higher performance key and the other is 
not special the operation that uses the special higher performance key must tolerate a vastly 
reduced level of security. The side that does not use such a special key retains its maximum 
security level. The total amount of time for the net encrypt/decrypt or sign/verify operation 
5 is about half of the worst case. This situation is the typical use of public key algorithms. 

The case where both sides use special higher performance keys is invalid. 
This is because a key cannot be special, higher performance without also having greatly 
lowered security, and it is degenerate for both sides of an encrypted channel to have virtually 
zero security. 

10 Other permutations of special higher performance pubUc key use are possible 

in various combinations of encryption and decryption, and signing and verifying. Table I, 
below, emmierates these possibilities for completeness, with the following terms used: 

• "Weak" means a special high performance, low security public key is 
used, while "Strong" means a non-special, low performance, high security 

15 public key is used. 

• "Auth Used?" means whether authentication is used in addition to 
encryption, versus encryption alone. 

• "Sec Level" means a relative weighing of total seciuity in a qualitative and 
subjective sense, comprising ratings of Lowest, Low, Medium, High, and 

20 Highest. 

• 'Terf Level" means the number of burdensome low-performance public 
key operations performed, comprising Highest = 0 burdensome 
operations. High = 1, Medium = 2, Low = 3, and Lowest = 4 operations. 

• An "Invalid & Degenerate" case is where the specific combination makes 
25 no security sense at all, such as where all keys are weak, zero-security 



keys. 



Case 


Auth 
Used? 


Encrypt 
Key 


Decrypt 
Key 


Signing 
Key 


Verifying 
Level 


Sec Level 


Perf 
Level 


Notes 


1 


No 


Weak 


Weak 


N/A 


N/A 


Lowest 


Highest 


Invalid & 
degenerate. 


2 


No 


Weak 


Strong 


N/A 


N/A 


Low 


High 


Used in 
DOCSIS. 
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3 


No 


Strong 


Weak 


N/A 


N/A 


Low 


High 


Invalid & 
degenerate. 


4 


No 


Strong 


Strong 


N/A 


N/A 


Medium 


Medium 


Atypical; 
Company 
private use 
only. 


5 


Yes 


Weak 


Weak 


N/A 


N/A 


Lowest 


Highest 


Invalid & 
degenerate. 


6 


Yes 


Weak 


Strong 


Weak 


Weak 


Low 


High 


Invalid & 
degenerate. 


7 


Yes 


Weak 


Strong 


Weak 


Strong 


Medium 


Medium 


Invalid &. 
degenerate. 


8 


Yes 


Weak 


Strong 


Strong 


Weak 


Medium 


Medium 


Typical 
standard use, 
e.g. Internet 


9 


Yes 


Weak 


Strong 


Strong 


Strong 


High 


Low 


Atypical; 
Company 
private use 
only. 


10 


Yes 


Strong 


Weak 


N/A 


N/A 


Low 


High 


Invalid & 
degenerate. 


11 


Yes 


Strong 


Strong 


Weak 


Weak 


Medium 


Medium 


Invalid & 
degenerate. 


12 


Yes 


Strong 


Strong 


Weak 


Strong 


High 


Low 


Atypical; 
Company 
private use 
only. 


13 


Yes 


Strong 


Strong 


Strong 


Weak 


High 


Low 


Atypical; 
, Company 
private use 
only. 


14 


Yes 


Strong 


Strong 


Strong 


Strong 


Highest 


Lowest 


Atypical; 
Company 
private use 
only. 



TABLET 

5 

Table I illustrates the basic problem with the use of special public keys, namely that there is 
no valid case where good security and good performance (i.e., low resource requirements) 
are both obtained. 
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SUMMARY OF THE INVENTION 



The present invention uses multiple public/private key pairs of varying levels 
of security. The lower-security level includes keys which are small in length, which are 
5 changed relatively often, and which require low resources to implement their coding 
functions. When it is desired to change key pairs of low security, a key pair at a higher 
security level (i.e., longer length keys) than the lower-security level keys is used to transfer 
the new lower-security public keys to devices using the higher-security keys. The higher- 
security keys can, in turn, be changed at a frequency lower than the lower-security keys. The 

10 higher-security keys require a higher level of resources to perform their coding operations. 
This approach of using keys of escalating levels of security to replace lower-security keys, 
where the higher-security keys require more resources, are more secure, and are replaced less 
often than the lower-security keys, can be followed as many times as is desired to create a 
hierarchy of public key uses with the result that the lower-security operations can be 

15 performed quickly while the overall system security is high. 

This allows public key encryption to be used in applications where the 
traditional key size would give unacceptably low performance; and provides a multi-level 
hierarchy, but avoids the performance problem by having keys lower in the hierarchy be of 
small size and thus higher performance. A variety of extensions and variations are possible, 

20 with different security and performance characteristics. 

In one embodiment, the invention provides a public key hierarchy in a digital 
telephony system. A three-tiered approach is used. The lowest security level keys are the 
"call" keys and are the smallest having a length of 512 bits. These keys are changed every 
few seconds. The next higher security keys are the "group" keys which have a length of 

25 1024 bits. These keys are changed about once a month. The highest security keys are the 
"unit" keys. The unit keys are 2048 bits in length and are hard-coded into their respective 
devices at the time of manufacture. The unit keys are not designed to be changed over the 
life of the unit. 

In another embodiment the invention provides a method for updating keys in a digital 
30 system used to transfer data over a network, wherein a plurality of devices are used to decode 
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data, wherein each device uses a first type of key to decode the data, a second type of key to 
decode substitute first keys, and a third type of key to decode substitute second keys, wherein 
the devices decode data at a first rate of decode occurrences, wherein each decode occuirence 
requires a first amount of time. The method comprising transferring encoded substitute first 
keys to the devices, wherein the transfers of the encoded substitute first keys occur at a 
second rate that is less than the first rate of decode occurrences, wherein the decoding of the 
substitute first keys requires a second amount of time that is greater than the first amount of 
time; and transferring encoded substitute second keys to the devices, wherein the transfers of 
the encoded substitute second keys occur at a third rate that is less than the second rate of 
decode occurrences, wherein the decoding of the substitute second keys requires a third 
amount of time that is greater than the second amoimt of time. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 shows an embodiment of the invention in a telephony system; 
Fig. 2 shows a multiple level PubUc Key hierarchy version of Fig. 1. 
Fig. 3 A charts encryption time as a fimction of key size; and 
Fig. 3B chargs mudulus size vs. complexity for exponentiation algorithms. 

DESCRIPTION OF THE SPECIFIC EMBODIMENTS 
For a general discussion of cryptography see, e.g., Schneier, Bruce A., 
"AppHed Cryptography" (2d Edition), 1996. 

Key Hierarchies 

The present invention uses a key hierarchy. This is a scheme where 
interrelated keys of varying levels of security work together in a system. A preferred 
embodiment of the invention is in a telephony system that employs a digital network for 
transmission. However, many other applications of the invention are possible. For example, 
the system can be employed where standard data transfers for numbers, text, email, image, 
audio or other information take place by sending small amounts of data at very frequent 
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intervals. Normally, this would make it impractical to use a public key approach where the 
keys are of sufficient length to give a moderate degree of security. 

Note that the examples discussed in this specification do not show the use of 
authentication but, instead, only deal with the use of public keys for encrypted delivery of 
5 keys. It should be apparent that authentication can be handled in a similar maimer. 

The invention is applicable to any system where a public key is used to deUver 
another public key, even if either of the public keys are also used to deliver a non- 
public/secret key in a symmetric system. 

Fig. 1 shows an embodiment of the invention in a telephony system. 

10 Fig. 1 shows a simple non-public key hierarchy. In Fig. 1, telephony system 

includes transmitter 102, communication channels 104 and receiver 106. The transmitter 
sends information to tiie receiver. There are three tiers of operation to which three separate 
key pairs are, respectively, assigned. A receiver, such as receiver 106 has a "unit key" 
specific and distinct to that receiver. The unit key is used to deliver messages that are only 

15 for tiie specific receiver. A group of receivers, such as those corresponding to users who 
have paid their telephone bill for a given month, together hold a shared "group key" 
conveying membership in that group. A stream of encrypted data (i.e. a telephone call) is 
encrypted under a 'Telephone Call Key", which must be possessed by the receiver that needs 
to be able to decrypt that call. 

20 A simple hierarchy for a non-public key, secret key or symmetric key system 

based on the keys above is where the Unit Key is used to deliver the Group Key, and the 
Group Key is used to deliver the Telephone Call Key. Thus, a imit key is used to encrypt a 
new group key by transmitter 102 in operation 110. The group key can only be decrypted by 
a single receiver, 106. However, multiple transmitters (not shown) would each encrypt the 

25 same group key in like operations 110 and transmit to their respective receivers (also not 

shown). In this way, multiple receivers can receive a common, and updated, group key firom 
an operation 110. 

Note that, although a one-to-one relationship is shown among the transmitters 
and receivers with respect to the unit keys, the actual implementation can be a point-to-point 
30 routing-based network such as the Internet. Thus, a list of unit keys for encoding, called a 



wo 00/45546 



:L o e e J. 2 . J. riniji;?- o ± 

PCT/USOO/02170 



9 

"keylist," is typically stored at a single transmitter to enable the transmitter to send new 
group keys to multiple receivers. 

The key hierarchy in this example is the linkage between Unit Key, Group 
Key, and Telephone Call Key. The Unit Key is at the top of the hierarchy, and the 
5 Telephone Call Key at the bottom. The purpose of this hierarchy is to protect the Telephone 
Call Data. 

The Unit Key used for decoding is not delivered through the communication 
channel, and is presumed to already be present in the receiver, such as after installation at 
manufacture time. 

10 All Group Key delivery messages sent over the communication channel are 

encrypted using the Unit Key. Group Key messages are typically sent at least once each 
month. 

All Telephone Call Key delivery messages sent over the channel are 
encrypted using the Group key. Telephone Call Key messages would typically be sent 

15 within a very short period of time after the call begins (e.g. within a second), to allow rapid 
access to a Telephone Call soon after a receiver initiates or responds to it. Telephone Call 
Key messages would change (along with the Telephone Call Key itself), each time a new 
Telephone Call occurred. 

All Telq)hone Call data sent over the channel is encrypted using the 

20 Telephone Call Key in operation 130, For a Transmitter to encrypt the Telephone Call in 
operation 130, it must create encrypted messages using the keys of the key hierarchy. The 
Telephone Call Key is used to encrypt the Telephone Call data in operation 130, and is itself 
encrypted by the Group Key in operation 120. The Group Key is encrypted for deHvery 
using the Unit Key in operation 110. The Unit Key is looked up on a list. Thereafter, the 

25 encrypted Telephone Call data, encrypted Telephone Call Key, and encrypted Group Key are 
sent into the commimication channel 104. 

For a receiver to decrypt the Telephone Call, it must process encrypted 
messages in a sequence that traverses the key hierarchy from top to bottom. The Unit Key is 
used to decrypt the delivered Group Key in operation 1 14, which is then used to decrypt the 
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delivered Telephone Call Key in operation 124, which is then used to decrypt the received 
Telephone Call data in operation 134. 

Fig. 2 shows a miiltiple level Public Key hierarchy version of Fig. 1. Note the 
differences that occur due to Fig. 1 describing a single key system, where the same key is 

5 used for both encryption and decryption, versus Fig. 2 which depicts a pubhc key system 
with public and private key pairs. Since Fig. 2 shows a public key system, the key to encrypt 
at the Transmitter 202 is not the same as the key to decrypt at the Receiver 206. As is typical 
with public key systems, encryption is performed with a public key, while decryption is 
performed with the corresponding private key. When a Transmitter 202 is encrypting a key 

10 for decryption use in the Receiver 206, the key must be a private key since only private keys 
can be used for the decryption operations 214, 224, and 234. 

As in Fig. 1 , all Telephone Call Data is encrypted using the Telephone Call 
Key in operation 230, except now operation 230 uses a different key than the decryption 
operation 234. Operation 230 uses the public Telephone Call Key, and operation 234 uses 

15 the private Telephone Call Key. Together, these two keys are a public key pair. For a 

transmitter to encrypt the Telephone Call in operation 230, it must create encrypted messages 
using the keys of this key hierarchy. The pubhc Telephone Call Key is used to encrypt the 
Telephone Call Data in operation 230, but is never itself encrypted and delivered to the 
receiver since the receive does not require the public key to decrypt. Instead, the private 

20 Telephone Call Key is encrypted in operation 220 using the Pubhc Group Key, and sent to 
the Receiver 206 for decryption using the private Group Key in operation 224. Similarly, the 
Private Group Key is encrypted in operation 210 using the public Unit Key, and is sent to the 
Receiver 206 for decryption in operation 214 using the private Unit Key. 

When applying public key technology to a key hierarchy such as in the system 

25 of Fig. 2, the performance problem is immediately encountered. The severity of this problem 
varies depending where it is used in the hierarchy: 

In the preferred embodiment, shown in Fig. 2, Unit Keys are used to decrypt 
Private Group Keys, which change approximately each month. A slow decryption speed for 
Private Group Keys due to the slowness of pubhc key algorithms is acceptable in this case, 

30 due to this infrequent use. 
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Private Group Keys are used to decrypt Private Telephone Call Keys, which 
must be delivered within about one second. A receiver that initiates or responds to a specific 
Telephone Call would therefore need to very quickly perform a public key algorithm-based 
Private Group Key decryption of a Private Telephone Call Key, which creates a performance 
5 challenge. This time period must be kept as short as possible to minimize consumer 
complaints, yet this is difficult when using slow public key algorithms. 

Private Telephone Call keys are used to decrypt Telephone Call data, which is 
delivered fairly rapidly and which would require several dozen or hundred public key 
decryptions per second to process in real time. This is a very severe performance challenge 
10 to a public key algorithm. 

In the present invention, keys at different levels of the hierarchy are changed 
at different rates. The Telephone Call Key public key pair changes with each new call. This 
means that the Telephone Call Key encryption and decryption, or "coding," functions need to 
have very fast performance (i.e., low resource needs). Fast performance is obtained by using 
15 keys of relatively short length. 

In pubhc key systems, encryption/decryptiori/sigriing/verifying performance is 
a cubic function of key size. Using a key that is half the size that would otherwise be used 
reduces the performance burden to 1/8 its former value, which is a 

reduction of 87.5%. Using a key that is one-fourth the size is a 98.4% reduction, while a key 
20 1/8 the size is a 99.8% reduction. This is shown in Fig. 3A. The performance problem can 

therefore be solved if smaller keys are used. 

But smaller keys have less security. To compensate for this reduced security, 

the smaller keys must have a shorter lifetime to reduce system risk accordingly. There is a 

direct tradeoff between the Ufetime of a key and its security level. Security level as a 
25 function of key size is shown in Fig. 3B for a class of Public Key algorithms known as 

"exponentiation ciphers." 

A basic concept of the invention is to build a public key hierarchy where the 

keys that would present an unacceptable performance burden are shortened to relieve that 

burden, but are then regularly and firequently replaced to compensate for the security lost due 
30 to their having been shortened. 
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In a preferred embodiment the following specific key sizes are used: 

1 . Let the Unit Key be a 2048 bit RSA key pair, which gives excellent 
long term seciuity. This key is never changed for the Ufe of the receiver. In one 
implementation, the time required to decrypt a Private Group Key using this key is about 1 

5 second. 

2. Let the Group Key pair be a 1 024 bit RSA key, which is delivered 
using the 2048 bit Unit Key no less often than monthly, or perhaps even weekly. Using this 
key to decrypt a private Telq)hone Call key will take 1/8 the time needed for the longer Unit 
Key, or 125 milliseconds. 

10 3 - Let the Telephone Call Key pair be a 5 1 2 bit RSA key, which is 

delivered using the 1024 bit Group Key. Using the Private Telephone Call Key to decrypt 
Telephone Call Data will take 1/64 second, or 15.6 milliseconds, for each 512 bits of data. 

The 512 bit RSA decryption of Telephone Call Data yields 512 bits of 
decrypted data each 15.6 miUiseconds, which is a total of 32,768 bits per second. Since 

15 voice traffic is usually at this rate or much lower (if compressed), this speed is adequate to 
handle a telephone call. In most applications pubHc key technology is not even considered 
for multiple-kilobit jqjplications, due to the performance problem. But with ttiis invention, it 
is quite feasible. If the data rate were faster than this, such as would be necessary with video 
data, tibien public key may not be used to protect Telephone Call Data. In that case, a high 

20 performance non-public key cipher such as the Data Encryption Standard would be used, 
where said key would be delivered by a public key (e.g. the 1024 bit Group key) or pubUc 
key hierarchy. 

Note that a public key hierarchy is fundamentally a key delivery mechanism, 
but that the keys delivered can comprise other public keys (either encrypt, decrypt, sign, or 

25 verify keys) or non-public keys (e.g. DES or Triple DES keys or HMAC keys) or both. A 
natural example would be where one level of a hierarchy (e.g. a 2048 bit Unit Key) delivers 
two keys. One (e.g. a 1024 bit Private Group Key) could be used as the next lower level key 
for deUvering information or keys in the key hierarchy (e.g. deUvering a 512 bit Private 
Telephone Call Key). The other (e.g. a 1024 bit Signing Group Key) could be used to 

30 authenticate (i,e. sign) messages or data sent firom that receiver. 
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In general, the invention provides a multiple-level public key hierarchy, where 
lower levels use smaller k&ys than higher levels, and where lower level keys are changed 
more often than higher levels to compensate for their lower security. Numerous 
embodiments of this idea are possible, ranging from the delivery of both encrypt keys, 
decrypt keys, signing keys, verifying keys, and/or non-public keys. 

Although the invention has been described with reference to specific 
embodiments thereof^ these embodiments are merely illustrative, and not restrictive, of the 
invention, the scope of which is determined solely by the appended claims. 
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WHAT TS CLAIMED IS: 

1 1. An asymmetric cryptographic processing system using a multiple key 

2 hierarchy, the asymmetric cryptographic processing system comprising 

3 a first key for performing asymmetric operations at a first rate, wherein each 

4 operation requires a first cryptographic processing processing time; and 

5 a second key for performing an asymmetric cryptographic processing 

6 operation to update the fibrst key, wherein the second key is used in cryptographic processing 

7 operations at a second rate that is less often than the first rate and that require a second 

8 cryptographic processing time greater than the first cryptographic processing time. 

1 2. The asymmetric cryptographic processing system of claim 1, wherein the 

2 system is used to cryptographically process and transfer digital voice data in a network. 

1 3. The asymmetric cryptographic processing system of claim 1, wherein the 

2 system is used to cryptographically process and transfer digital audio data in a network. 

1 4. The asymmetric cryptographic processing system of claim 1, wherein the 

2 system is used to cryptographically process and transfer digital video data in a network. 

1 5. The asymmetric cr3^tographic processing system of claim 1, wherein the 

2 system is used to cryptographically process and transfer digital data in a network. 

1 6. The asymmetric cryptographic processing system of claim 2, wherein the 

2 second key is hard coded into the system at the time of manufacturing the system. 

1 7. The as3amnetric cryptographic processing system of claim 6, wherein a 

2 plurality of digital cryptographic processing systems are coupled by a telecommunications 

3 system, wherein the second key is distributed to two or more of the asymmetric 

4 cryptographic processing systems via the telecommunications system. 

1 8. A method for updating keys in a digital system used to transfer data in a 

2 telecommunications system, whereia a plurality of devices are used to asymmetrically 

3 cryptographically process data, wherein each device uses a first type of key to process the 

4 data, a second type of key to process substitute first keys, wherein the devices process data at 

5 a first rate of processing occurrences, wherein each processing occurrence requires a first 

6 amount of time, the method comprising 



J„€:iO^^SJ..iZ JLZ^eT^tj J.. 

wo 00/45546 PCT/USOO/02170 
15 

7 transferring cryptographically processed substitute first keys to the devices, 

8 whereiQ the transfers of the cryptographically processed substitute first keys occur at a 

9 second rate that is less than the first rate of processing occurrences, wherein the processing of 

10 the substitute first keys requires a second amount of time that is greater than the first amount 

11 of time. 

1 9. The method of claim 8, wherein the steps are stored in a machine readable 

2 medium. 

1 10. A method for providing secure data transactions in a teleconraumications 

2 system, wherein a digital processing device receives information fi^om the 



3 telecommunications system, wherein the digital processing device uses a first asymmetrical 

4 cryptographically processed key to perform an asyrmnetric cryptographic processing 

5 operation to decode the information, wherein the cryptographic processing operation is at a 

6 first level of complexity requiring a first amount of resources by the processing device, 

7 wherein the cryptographic processing operation is performed at a first rate of cryptographic 

8 processing operations per unit time, the method comprising 



9 transferring a second asymmetrical cryptogr^hically processed key to the 

10 digital processing device, wherein the second asymmetrical cryptographically processed key 

11 is used in an as3mimetric cryptographic processing operation at a second level of complexity 

12 requiring a second amount of resources by the processing device that is higher than the first 

13 amount of resources; 

14 updating the first asymmetrical cryptographically processed key fi:om time-to- 

1 5 time, wherein the updating of the first asymmetrical cryptographically processed key occurs 

16 at a second rate of cryptographic processing operations per imit time that is less than the first 

1 7 rate of cryptographic processing operations per imit time, wherein the updating includes the 

18 following substeps; 

19 encoding a substitute first asymmetrical cryptographically processed key with 

20 a second key, so that the resulting cryptographically processed substitute first asymmetrical 

21 cryptographically processed key is decodable by the second asymmetrical cryptographically 

22 processed key; and 

23 transferring the substitute first asymmetrical cryptographically processed key 

24 to the digital processing device so that the substitute fibrst asymmetrical cryptographically 
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25 processed key is used in subsequent cryptographic processing operations by the digital 

26 processing device. 

1 11. The method of claim 7, further comprising 

2 transferring a third asymmetrical cryptographically processed key to the 

3 digital processing device, wherein the third asymmetrical cryptographically processed key is 

4 used in an asyrmnetric cryptographic processing operation at a third level of complexity 

5 requiring a third amoimt of resources by the processing device that is higher than the second 

6 amount of resources; 

7 updating the second asymmetrical cryptographically processed key from time- 

8 to-time, wherein the updating of the second asymmetrical cryptographically processed key 

9 occurs at a third rate of cryptographic processing operations per unit time that is less than the 

1 0 second rate of cryptographic processing operations per unit time, wherein the updating 

1 1 includes the following substeps; 

12 encoding a substitute second asymmetrical cryptographically processed key 

13 with a third asymmetrical cryptographically processed key, so that the resulting 

14 cryptographically processed substitute second asymmetrical cryptographically processed key 

15 is capable of being cryptographically processed by the third asymmetrical cryptographically 

16 processed key; and 

17 transferring the substitute second asymmetrical cryptographically processed 

18 key to the digital processing device so that the substitute second asymmetrical 

19 cryptographically processed key is used in subsequent cryptographic processing operations 

20 by the digital processing device. 

1 12. The method of claim 10, wherein the resources include processing time. 

1 13. The method of claim 10, wherein the resources include transistor density 

2 on an integrated circuit. 

1 14. The method of claim 10, wherein the resources include memory capacity. 

1 15. The method of claim 1 0, wherein the resources include data bandwidth. 
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(57) Abstract 

Multiple public/private key pairs of varying levels of security are used to provide a high level of security while still allowing fast 
processing of encrypted information. The lower-security level includes keys which are small in length, which are changed relatively often, 
and which require less or fewer resources to implement their functions (130), (134). When it is required to change key pairs of low security, 
a key pair at a higher security level (i.e, longer length keys) than the lower-security level keys is used to transfer the new lower-security 
public keys to devices using those keys. The higher-security keys can, in turn, be changed at a frequency lower than the lower-security 
keys. The higher-security keys require a higher level of resources to perform their coding operations (120). (124). This approach of using 
keys of escalating levels of security to replace lower-security keys, where the higher-security keys require more resources, are more secure, 
and are replaced less often than the lower-security keys, can be followed as many times as is desired to create a hierarchy of public key 
uses with the result that the lower-security operations can be performed quickly while the overall system security is high. 
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